I think it's good to have a way to toggle inlay hint, because it can be too verbosely.

This is how I do on my config:

if client.server_capabilities.inlayHintProvider then
    map('<leader>ih', function() vim.lsp.inlay_hint.enable(0, not vim.lsp.inlay_hint.is_enabled()) end, "Toggle [I]nlay [H]int")
end

Agreed. A toggle or configurable is needed here.

If a toggle is added I would suggest to use <leader>ti

Maybe since this affects code stuff and uses LSP it should be <leader>ci?

@VlaDexa Thanks for your work thus far. If you're still intrerested in getting this merged, please add a toggle as folks have detailed. I don't honestly care which key bind you use. People can always change it :)

Sorry to have more thought here: I don't think <leader>ci match the command naming style in kickstart, because c doesn't show in help message.

Here are some examples of how key binds to help messages:

map('<leader>ca', vim.lsp.buf.code_action, '[C]ode [A]ction')
map('<leader>rn', vim.lsp.buf.rename, '[R]e[n]ame')
map('<leader>ds', require('telescope.builtin').lsp_document_symbols, '[D]ocument [S]ymbols')

Every character has a highlight in help message(which wrapped with []). It's good for users to remember key bind. So I'd suggest to change keybind to <leader>it, or changing help message to [C]hange [I]nlay hint

More thoughts are good so long as the contributor of said thoughts helps find concordance and we can move forward, assuming folks agree that we all want this optional feature.

<leader>ti [T]oggle [I]nlay still makes the most sense to me :)

If we're going by the starting letters of the help message logic, then sure, I agree that ci is not conforming. Then, I think that it being <leader>th is easier to remember, since you don't need to know that it toggles something inlay, but enables hints.

<leader>th is fine with me 👍